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Abstract 

The constraints of future Exploration Missions will require unique integrated system health 
management capabilities throughout the mission. An ambitious launch schedule, human-rating 
requirements, long quiescent periods, limited human access for repair or replacement, and long 
communication delays, all require an integrated approach to health management that can span distinct, yet 
interdependent vehicle subsystems, anticipate failure states, provide autonomous remediation and support 
the Exploration Mission from beginning to end. Propulsion is a critical part of any space exploration 
mission, and monitoring the health of the propulsion system is an integral part of assuring mission safety 
and success. Health management is a somewhat ubiquitous technology that encompasses a large spectrum 
of physical components and logical processes. For this reason, it is essential to develop a systematic plan 
for propulsion health management system development. This paper provides a high-level perspective of 
propulsion health management systems, and describes a logical approach for the future planning and early 
development that are crucial to planned space exploration programs. It also presents an overall approach, 
or roadmap, for propulsion health management system development and a discussion of the associated 
roadblocks and challenges. 


Introduction 

Propulsion is a vital part of any space exploration mission, starting from launch vehicles, to upper- 
stage-to-orbit or in-space propulsion. Reliable and safe operation of the various propulsion systems is 
critical to achieving mission success; it must, however, be performed at an acceptable cost. Monitoring 
the health of the propulsion system and other subsystems is an integral part of assuring mission safety and 
success. The current paradigm to such monitoring consists mainly of having a suite of sensors on-board 
which can sense physical quantities related to the performance and/or operational status of various 
propulsion-related components. Typically only safety critical decisions are made on-board with limited 
remediation such as engine shut down; or, automated redundancy management is designed into the 
systems where backup functional components would be activated in the event of faults. Some of the 
information is telemetered to the ground for review and analysis by teams of experts. These ground-based 
teams oversee the on-board monitoring system and react to “off-nominal” situations, performing 
diagnostic analysis and remediation to ensure safety and mission success. 
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This current approach to “ground-based diagnostics and remediation” requires a readily available 
team of experts; each highly trained in a particular area. It is very human intensive and costly in terms of 
continued operations. In addition, it tends to be quite conservative with regard to safety - the result of 
avoiding negative consequences due to human error. This approach is also restricted by the need for 
communication between space vehicle and earth - there can be substantial time delays associated with 
this communication which can result in catastrophic failures if any safety critical conditions are not 
diagnosed in a timely manner. With the advancement of sensor technology and computer capability, more 
extensive signal processing and diagnostic functions offer potential solutions to complex system health 
management problems. For space propulsion systems, effective propulsion health management systems 
(PHMS) must be available early in the program to support the design of propulsion systems that are safe, 
reliable and highly autonomous. Early PHMS availability is also needed to promote design for affordable 
operations; increased knowledge of functional health provided by PHMS supports construction of more 
efficient operations infrastructure. However, lack of early PHMS inclusion in the system design process 
could result in retrofitting health management systems; thereby increasing program cost and risk due to 
increased instrumentation and computational complexity. 

Health management is a somewhat ubiquitous technology that encompasses a large spectrum of 
physical components and logical processes. For this reason, it is essential to develop a systematic plan for 
PHMS development. The objective of this paper is to provide a high level perspective of propulsion 
health management systems, and to describe a logical approach for future planning and early development 
crucial to support of planned space exploration programs. Discussion will begin with a description of a 
PHMS roadmap that breaks down the system into a number of products specific to PHMS. Important 
lessons learned from previous aerospace and aeronautical engine health management programs are then 
described. These lessons shape perspectives of where propulsion health management systems are now, 
and serve as a natural springboard for discussion of where PHMS development needs to go. Finally, the 
logical basis for treating propulsion health management as a system-centered solution that impacts not 
only operations, but also design and robust knowledge capture, is then presented. 

PHM Roadmap Overview 

Because of the high energy and large risk, propulsion systems are often focal points for health 
management (HM) activities and, therefore, aerospace programs invest substantial resources in HM 
technology development and application. Optimum performance and effectiveness of a HM system is 
achieved when its development coincides with the development of the system whose health it is being 
tasked to manage (ref. 1). It is much less effective and efficient when it is implemented after the fact. In 
fact, the HM system design, like the monitored system design, is a continuous, iterative process that 
requires a symbiotic relationship with the monitored system. As the monitored system design becomes 
more refined and focused, the HM system can also be refined; and as the HM system develops, it can 
impact the monitored system design and operation. The iterative nature of this design process also 
requires a symbiotic relationship between the subsystem developers (i.e., domain experts) and the HM 
system developers. These two groups of experts must work together cooperatively if the final design is to 
meet requirements for performance, operation, and health assessment. 

In general, the PHMS development process requires a thorough understanding of the system being 
managed. Knowledge acquisition from domain experts is essential in establishing the scope of a PHMS. 

A clear set of system requirements and operations concept are some of the first essential elements. A 
Failure Modes and Effects Criticality Analysis must be performed to identify the critical faults and 
document how those faults manifest themselves in the system. Also, when development of a PHMS is 
incorporated early in the system design, little, if any, test data is available and therefore numerical models 
of the system are essential. These system models must have sufficient detail and complexity so that they 
provide a sound basis for developing and testing the required HM system. 

At the same time, the developing HM technologies can impact the monitored system design. 

Identified critical failure modes may only be covered through the HM system if sufficient sensor data is 
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available. In some cases, sensors may need to be added to the system to enable detection or provide 
sufficient redundancy for robust HM operation. Failure modes beyond current PHMS capabilities may 
force system re-design or impact operation in order to remove or mitigate the risk to the propulsion 
system. System designs which have rigorous fault/hazard analyses and HM development processes will 
anticipate and address potential problems earlier in the design cycles where resolutions will not require 
costly retrofits and delays. 

Focusing on the design requirements for the monitored system, as it pertains to development of the 
PHMS, the elements of the development process may be broken-down as follows: 

• Sensor Selection 

• Data Validation 

• Fault Detection 

• Fault Isolation 

• Information Fusion 

• Prognostics 

• Verification and Validation 

Here, it should be noted that, beyond the domain of the PHMS, this design approach and its elements 
are characteristic of a more general HM system that can readily be applied to other subsystems. 

Figure 1 illustrates the process for developing a PHMS within the propulsion system design and 
development process. Each of the previously given elements are listed within the diagnostic/prognostic 
functions section, except for sensor selection and verification and validation which are solely design 
elements. Note the intentional use of a bus, rather than top-to-bottom data through-flow. The data bus was 
included here for two reasons. First, it generalizes the discussion by minimizing the focus on data flow 
which can be system dependent. A given PHMS will be designed to meet system specific requirements, 
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Figure 1. — Propulsion health management system design and development process. 
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and all of the elements shown may not be needed or desired. By providing a general path for data flow, 
PHMS elements can be removed from or incorporated into this structure without re-routing the data flow. 
Second, it is also illustrative of the fact that elements of the PHMS system may not necessarily operate 
sequentially, that is, data in the PHMS may be available to the elements as needed rather than passed from 
one element to the next. 


PHMS Roadmap Elements 

In this section, each of the PHMS roadmap elements are discussed. In general, the discussion for each 
element includes: element definition, motivation, benefits, prior application with lessons learned, and 
challenges. 

Before proceeding with the individual discussions, it is constructive to point out that clear boundaries 
between the PHMS elements do not exist. In fact, although figure 1 shows each PHMS element as a 
distinct entity, there can be significant overlap. For example, Data Validation, which detects and isolates 
failures in sensors, could be considered a subset of Fault Detection and Fault Isolation. And while Fault 
Detection can stand alone, it is clearly a crucial and defining element for the Fault Isolation and 
Prognostics technologies. Despite this overlap between the elements, for the purposes of this discussion, it 
is useful to address technology capabilities and challenges for each element individually. 

Sensor Selection 

Sensor data are the basis for evaluating the performance of any complex system; and careful selection 
and implementation of sensors is critical to enable high fidelity system health assessment. The purpose of 
the sensor selection process is to identify sensors that will fulfill requirements for health assessment of the 
monitored system while optimally meeting the design constraints. The sensor selection process should 
allow the designer to optimize such things as operational costs (e.g., purchase, installation, and 
maintenance), weight, and reliability in addition to health assessment performance. Additionally, 
optimization-based sensor selection processes can be used to prioritize the funding and development of 
new sensors. This would be accomplished by characterizing sensors proposed for development, adding 
them to the candidate sensor suites, then evaluating the results of the selection and optimization process. 
Prioritization could then be based in part on whether or not a given sensor is identified with an optimal 
sensor suite. This approach can provide managers with a tool for prioritizing the distribution of limited 
research and development funds. 

Sensor selection is not unique to propulsion health assessment. In many technology areas, substantial 
research has been conducted to achieve optimum sensor and actuator placement within a given system 
(refs. 2 and 3). To meet the goal of optimal sensor placement, much of the associated research has 
focused on the establishment of proper performance and control design metrics and the development of 
techniques to optimize the solution search process. 

References 3 and 4 present one sensor selection process named the Systematic Sensor Selection 
Strategy (S4). The S4 is a model-based procedure for systematically and quantitatively selecting an 
optimal sensor suite to provide overall health assessment of a given host system. The S4 procedure, 
shown in figure 2, has been applied to the Rocketdyne RS-83 and RS-84 boost stage liquid rocket engines 
and the Space Shuttle Main engines (SSMEs). In each case, the S4 demonstrated the ability to direct 
sensor selection decisions based on available system failure information and design constraints imposed 
on the process. Pratt & Whitney Rocketdyne has continued to employ this approach on their current J-2X 
engine design for the NASA Constellation program. 

S4 can be logically partitioned into three major subdivisions: the knowledge base, the down-select 
iteration, and the final selection analysis. The knowledge base consists of system design information and 
heritage experience together with a focus on components with health implications. The sensor suite down- 
selection process identifies a group of sensors that provide good fault detection and isolation for targeted 
fault scenarios. This process is composed of three basic components: a system health diagnostic model, a 
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Figure 2. — Procedure for Systematic Sensor Selection Strategy (S4). 

merit algorithm, and a selection algorithm. In the final selection analysis, a statistical evaluation algorithm 
provides the final robustness test for each down-selected sensor suite. 

Though this systematic sensor selection process was developed to enhance design phase planning and 
preparation for space propulsion health management, the S4 process can also be applied to a broad range 
of non-propulsion health management systems (e.g., power, communications, and fluid storage/feed 
systems) that are part of the NASA Exploration Systems architecture. 

Regardless of the applied methodology, the sensor selection element should be flexible and applicable 
in several areas. 


• Able to incorporate the best system design information available throughout the design cycle of 
the monitored system. 

• Applicable to multiple types of systems (e.g., propulsion, electrical, hydraulic, etc.) and 
heterogeneous sensor networks (e.g., pressures, temperature, accelerometers, etc.) 

• Able to incorporate weighting factors that represent both fault criticality and sensor costs. 

• Applicable across various phases of system operation (e.g., pre-launch, flight, quiescence, 
shutdown, post-flight.) 

• Modular to handle various evaluation and optimization techniques. 

There are a variety of challenges associated with optimization of sensor suites. One challenge is the 
lack of models and health data early in the design process when sensor selection can provide the most 
benefit to the design process. Another challenge is balancing the need to have metrics functions that are 
well understood and easily defended against the desire to reach a globally optimal result. The first 
objective can yield relatively simple metric functions that produce suboptimal results; while the later 
objective can result in a poorly understood, complex, computationally-intensive, multi-dimensional, and 
potentially, over-constrained search space. 
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Data Validation 


Data validation is the process of analyzing sensor signals to insure that the data accurately represents 
the system state being measured. Data validation is an important element in the overall health assessment 
process as it can prevent safety system false alarms, unnecessary shutdowns, and improper system 
responses by ensuring that automated health management systems “reason” with valid (or qualified) data. 
Proper fault detection and isolation can only be performed when information provided by the sensors is 
valid. 

As shown in figure 3, conventional techniques, such as limit checks, can identify hard sensor failures, 
while more advanced techniques (e.g., neural networks (ref. 5), model-based analytical redundancy 
(ref. 6), Kalman filters (ref. 7) and wavelets (ref. 8) have been applied to detect subtle or soft sensor 
failures, such as drift and noise. One such project developed an advanced sensor validation technology 
utilizing analytical redundancy with a Bayesian Belief network to provide real-time solutions for RS-83 
and RS-84 propulsion systems (ref. 9). The analytical redundancy relationships between sensors in the 
engine were used to establish a belief network that would identify faulty sensors and provide a 
quantitative confidence measure for the identified sensor faults. The result of this effort is contained 
within a commercially available software suite, the Data Quality Validation Studio produced by Expert 
Microsystems, Inc. More recently, data validation is being incorporated into the design of the abort 
system for Ares I, NASA’s next manned launch vehicle. There, it will provide for the safety of the crew 
by identifying faulty sensor data before they are used in critical operational decisions such as abort. 

Data validation is vital for all systems, because system performance evaluation and system health 
assessment rely primarily on sensor information. For Exploration Systems Missions where automation 
and remediation are based exclusively on sensor data and limited human input, advancement of these 
technologies to ensure optimum implementation, development and certification is required. While 
conventional approaches have a legacy of implementation, more advanced approaches that focus on 
subtle sensor failures must demonstrate the ability to perform in the presence of multiple sensor failures 
and common-cause sensor failures. These advanced systems must also be prepared to face the challenge 
of avoiding misdiagnosis during system component failures, as well as, detecting the failure of feedback 
sensors in closed-loop control systems. 


Fault Detection 

Fault detection is basically the determination that something is awry with the system functionality. In 
this PHMS roadmap, it is focused solely on diagnosing system, rather than sensor, behavior. The 
detection portion of the PHMS must be capable of distinguishing nominal from truly anomalous 
conditions. Fault detection typically works hand-in-glove with fault isolation, as fault detection is most 


Individual 


Multi-Sensor 


Sensor 


Validation 


Validation 


Redundancy-based 

r 

Screening/filtering 


analysis: 

• Hardware - 
homogenous comparison 
of redundant sensors 


for gross faults: 

•Amplitude Limits 
• Rate-of-change 
Limits 


r 


•Analytical - 
heterogeneous 
comparison physically 


• Noise Limits 


i 


dependent sensors 



Figure 3. — High-level view of data validation. 


Fault 

Decision 

Logic 


Determine which 
sensors are faulty 
(not valid) based 
on available info 
and analysis 


NASA/TM— 2007-2 15034 


6 





effective when the fault can be isolated to a specific component or cause. Together, fault detection and 
isolation provide a basis for remediation that can result in a variety of scenarios from successful 
completion of the mission to a crew-saving abort sequence. 

There are many detection techniques available. Some address specific system faults while others will 
monitor the system as a whole, using a model-based approach. Implementation will depend on the extent 
of understanding of the nominal propulsion system functions. Santi (ref. 4) and Butas (ref. 10) proposed 
an approach where specific system health parameters from available simulations are extracted to establish 
a fault data reconciliation matrix. Observations are then processed utilizing this matrix to detect and 
identify the anomaly. 

If the system functions are unknown or uncertain to a great extent, then empirical approaches may be 
required. These approaches may include the application of data mining techniques to historical data to 
develop complex indicators of previously undiscovered relationships among available observations and 
the fault events (ref. 11). Upon detection and identification of events within the historical archives, 
algorithms can be developed to specifically monitor for those precursors that identify specific failure 
conditions. Another empirical approach taken by researchers is to define the nominal system operating 
envelope by using statistical methods, neural networks (ref. 12), radial-basis networks (ref. 13), or other 
empirically derived models (ref. 14), with detection being any observation statistically beyond the defined 
boundaries. 

Fault detection technology requires an understanding of the monitored system and the potential 
modes of failure. Merely announcing an anomalous event is not sufficient; there must be a correlation of 
that event to some failure condition of the system, otherwise the detection is merely an academic exercise. 
Current detection processes called “redlines” are set on certain system parameters. When exceeded they 
indicate that system is experiencing a physical state beyond its safety design constraints. The redline 
detection does not necessarily indicate what is causing the failure, only that one is occurring. Advanced 
detection techniques may be involved in monitoring key health specific parameters or may need to be 
combined with diagnostic analysis to identify a specific failure condition. Doing so may enable various 
response activities that could allow the mission to continue. 

One key challenge in this technology field is the acquisition of system and failure information. 
Especially early in the system design, there is limited domain knowledge and what is available is often 
inferred from other related or similar systems. Also due to the destructive nature of the fault conditions 
for propulsion systems, there is often little failure data sufficient to characterize the system response to 
those failures. Therefore verification and validation is often via simulation and dependent on simulation 
fidelity. 

Another challenge area is the balance between missed detections and false alarms. Missed detections 
or detections delayed due to uncertainty could result in catastrophe; but a false alarm which forces the 
system to respond to a nonexistent condition can also lead to disastrous consequences along with a loss of 
confidence in the detection system. The detection methods must be established with a high level of 
confidence in proper detection and still enable a timely response to the situation. 

Fault Isolation 

We define fault isolation as the capability to distinguish between failure signatures, thus 
characterizing the failure condition to a particular faulty component or cause. In general, once an anomaly 
is detected the PHMS must identify the failure to ensure proper response to the condition. That is, unless 
the detection is a direct limit (e.g., redline limit) of the physical system or an indication of loss of 
structural integrity (e.g., breakwire indication) which requires an immediate single response. Fault 
isolation is the further resolution of the fault detection results to distinguish between various failures or 
failure groups. This resolution is only necessary when the proper identification of a fault affects the 
system response or remediation strategy. Isolation is not required when groups of failure modes have 
similar fault signatures with the same remediation strategy. 
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Similar to the development of the fault detection process, fault isolation requires an understanding of 
the monitored system and the potential modes of failure, as well as, the distinguishing characteristics 
between failure modes that require different system responses. Fault isolation can be performed in a 
number of ways, e.g., using rule-based reasoning (ref. 15), model-based reasoning (ref. 3), or a hybrid 
architecture (ref. 16) that utilizes both rule-based and model-based analysis for fault identification and 
isolation. 

One example of a demonstrated fault isolation system was the Propulsion IVHM Technology 
Experiment (PITEX) system. PITEX is a real-time model-based diagnostic system for the main 
propulsion system of the X-34 reusable launch vehicle (ref. 17). This diagnostic system was demonstrated 
in a simulation-based environment that used detailed models of the propulsion subsystem to generate 
nominal and failure data during the captive carry operational phase - the most safety-critical portion of 
the X-34 flight. Since no system-level testing of the X-34 Main Propulsion System (MPS) was performed, 
these simulated data were used to develop and demonstrate the software system. To accomplish the 
demonstration, advanced diagnostic and signal processing algorithms were developed and successfully 
tested in real-time on flight-like hardware. 

Fault isolation capability must also be able to utilize heterogeneous pieces of information and data. 
Because direct measurements from the failed component are often unavailable, indirect measurements 
must be used to infer the condition. The impact the failed component has across the system is therefore 
combined into a deductive chain of reasoning that should point to the situation at hand. To arrive at an 
acceptable isolation solution, data fusion technologies (discussed in the following section) may be 
required so that isolation algorithms can use health-related data from measuring systems that do not align 
in time. In addition, alternative strings of confirming information increase the confidence in the final 
isolation analysis, and make the PHMS robust to loss of data due to sensor fault or communication loss. 

The challenge of fault isolation technology is similar to that of fault detection with respect to the 
availability of system failure information. The lack of fault data makes verification and validation 
difficult and reliant on simulation of the faults. Due to this, sophisticated fault isolation strategies often 
lack confidence at the program level and are not, therefore, incorporated into on-board flight software. 

Information Fusion 

Information fusion is a cross-cutting technology that aligns data from similar and disparate sources in 
time and uses those data to perform higher-level system diagnosis. Often information from one subsystem 
must be fused with external pieces of data in order to establish a complete picture of the events. Even 
within subsystems, distinct instrumentation networks (e.g., accelerometers and flow-path sensors) result 
in disjointed bits of information that could be correlated to increase decision confidence. Data Fusion is 
an enabling technology for long duration missions where self diagnosis of very complex systems may be 
the difference between mission success and failure. 

An example of research to implement information fusion technology occurred under NASA’s 
Aviation Safety and Security Program, where NASA and Pratt & Whitney collaborated to develop 
Information Fusion technologies (refs. 18 and 19). A wealth of aircraft turbine engine data is available 
from a variety of sources including on-board sensor measurements, operating histories, and component 
models. The challenge is how to maximize the meaningful information extracted from these disparate 
data sources to obtain enhanced diagnostic and prognostic information regarding the health and condition 
of the engine. To address this challenge, NASA and Pratt & Whitney have developed the modular 
hierarchical information fusion architecture shown in figure 4. The efficacy of this architecture was 
demonstrated through the fusion of two gas path analysis algorithms, the Enhanced Self-Tuning Onboard 
Real-time Model (eSTORM) and a neural network-based Gas Path Anomaly Detector (GPAD). This 
fusion allowed the system to detect and isolate both sensor and component faults. Furthermore, once a 
sensor fault was detected, it was accommodated (i.e., remediation strategy) by replacing the faulty 
physical measurement with an estimated value. This allowed the system to continue to accurately estimate 
component performance even in the presence of a sensor fault. 
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Figure 5. — Distinguishing diagnostics from prognostics. 

Prognostics 

Prognostic analyses, as the final level of inference, incorporate much of the previously discussed 
technologies and extends the analyses to define the life usage and remaining life of a system or 
component. Beyond the effort of early fault detection and isolation, prognostics attempts to quantify the 
remaining time that the system function will be available. To differentiate prognostics from diagnostics, 
Smith (ref. 20) uses a diagram similar to that shown in figure 5. Here, diagnostic analysis takes place after 
a failure has occurred, while prognostic analysis occurs prior to failure. 

Prognostic analyses can be separated into either near-term prognostics or far-term prognostics. 
Reference 21 provides a survey of current prognostics activities within the aeronautical and aerospace 
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fields. Near-term prognostics are the ability to determine the remaining time available to the system 
before the failure reaches a defined catastrophic level. Often this catastrophic level is that where the 
failure can no longer be tolerated by the system, remediation is useless and the result will be loss of 
mission and/or loss of crew. Near-term prognostics are used in the real-time, on-line mode and provide 
the response system with an indication of how much time remains before it must respond to a given 
situation. Baseline prognostics may merely be a predefined time allocation from initial detection until 
catastrophic condition based upon historical data or simulation analysis. More sophisticated prognostic 
strategies may be capable of updating the projected remaining time based on progression of the failure; of 
course, this additional capability requires a thorough understanding of relevant failure mechanisms. 

Long-term prognostics provide system health assessment for maintenance scheduling and logistics 
support. This analysis does not require real-time, on-line processing and is based on projected 
performance of the system. While immediate remediation may not result from this analysis, immediate 
planning may. This planning may indicate a need for repair prior to the next scheduled activity involving 
the component; or, it may require an alteration in mission to handle the change in performance of the 
failing component. While the failures addressed here are not immediately life-threatening, for long 
duration missions to the Moon or Mars, they could have devastating results if not properly addressed. An 
example of this long-term prognostics development would be the Air Force’s Joint Strike Fighter program 
(ref. 22), where the driver for the technology development is in fleet logistics, low life cycle costs, 
opportunistic maintenance and quick turnaround times. 

As reported in reference 21, development and implementation for prognostic systems had been very 
limited. Issues of data availability for development and testing of this technology are even more severe 
than the other PHMS elements. Offering the ability to detect and isolate a fault condition requires a high 
level of verification to instill confidence in the PHMS output; adding the additional layer of sophistication 
required to project the fault progression will greatly exacerbate that verification effort. 

PHMS Verification and Validation 

Verification and validation are critical to the design and implementation of any flight software, 
including PHMS. Diagnostic algorithms and the tools used to develop them must be certified to satisfy 
the systems requirements; certified in their development process and in their performance. The diagnostic 
system itself should minimize its negative impact on the system and provide a substantial overall benefit. 
In other words the health management system should be resolving faults, not creating faults. 

Brown (ref. 23) develops a set of requirements that diagnostic systems should aspire to. These include 
the ability to distinguish between nominal and anomalous operation (Fault Detection), the ability to 
distinguish between failure modes (Fault Isolation) and robustness to nominal system variations and 
external influences, such as sensor faults. Additionally, the requirement of timeliness should be added to 
ensure that the diagnostic performance provides sufficient time for the system to respond. Also the PHMS 
should demonstrate the ability to perform within system resource requirements, computer processing units 
and memory, and robustness to any resource stressed situations. Finally, the PHMS should be able to 
recover or restart from a power or data interruption with minimal impact to the health assessment 
performance of the system. 

All of these PHMS requirements require significant data for development, testing and demonstration. 
Because of safety and program constraints, propulsion systems lack significant failure data; historically 
there have been no test programs where faults were intentionally inserted into flight or flight-like systems 
to determine the fault progression and system response. Instead, failure data is only coincidentally 
available from performance testing or flights, or from simulation. Therefore simulation testing will be a 
dominant capability to develop to support the PHMS verification and validation process. Pecheur (ref. 24) 
surveyed several diagnostic system verification and validation methodologies and each relied heavily 
upon simulation capabilities. To that end, simulation test beds, similar to the data qualification test bed 
implemented by Sowers (ref. 25), must be developed along with high fidelity simulations of the 
monitored system. 
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PHMS Impacts 

Propulsion systems provide a critical function for any space vehicle. However because of their 
volatile nature, propulsion system-related failures are generally severe and result in extremely adverse 
consequences. In addition, propulsion systems can not be treated as a separate disjointed element from the 
rest of the vehicle. Failure conditions from the propulsion element can be felt throughout other 
subsystems, e.g., structure, power and avionics. For the proper evaluation of propulsion health, it is 
important that all available and pertinent pieces of information from the vehicle are available. In addition, 
propulsion systems are complex and cannot easily be segmented into distinct components and treated 
separately for health assessment purposes. Propulsion systems are often complex elements with various 
feedback paths that faults conditions may impact. Therefore the entire propulsion system should be 
diagnosed by the PHMS. 

In studies of aeronautical and space vehicles, propulsion failures are among the most prevalent and 
catastrophic of all the system failures. SAIC (ref. 26), reporting in a probabilistic risk assessment of the 
Shuttle, indicated a risk dominance of propulsion systems. Of the top 20 risk-contributing accident 
sequences, thirteen were associated with the Space Shuttle Main Engines or the Solid Rocket Boosters. 
Therefore, the ability to resolve and reconcile these failures has a very large impact on the overall system 
design. It is extremely important that PHMS design considerations are initiated at the very beginning of 
the system design analysis. Utilizing available PHMS technologies in the same manner as available 
control and sensor technologies when assessing the system design will enable a safe and reliable design. 
Specific impact areas include enhanced autonomous control in response to anomaly conditions, improved 
operational planning, cost effective maintenance for cause, informed design requirements, and more 
efficient test program planning. 


Concluding Remarks 

Health assessment of propulsion systems is crucial for the safe, reliable operation of any space 
vehicle. PHMS must be involved early in the system design process to take advantage of any potential 
benefit of the available technologies and avoid retro-fit costs. This paper identified a potential PHMS 
roadmap, breaking down and describing potential technology areas that provide building blocks for a 
PHMS. These technologies are not independent and distinct of each other and often require each other in 
order to provide the overall PHMS safety and reliable capability. In addition to the development of the 
diagnostic strategies, development of support elements such as system simulations and V&V test-beds, 
must be considered in the PHMS roadmap plan. 
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